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[57] ABSTRACT 

The version negotiation of the present invention insures that 
there will always be an ejected data and control interface 
between a Dynamic T^inV library (DLL) and an application 
program that relies on the DLL. The application program 
makes an initial call to die DLL that specifies Ihe DLL 
version with which it prefers to q)erate. The DLL compares 
this prefeired version number to the version numbers that it 
supports, whidi are in a supported DLL version table within 
the DLL. If the preferred version matches one of the table 
entries, then the DLL returns an "OK" flag to the application 
program. In this case, the application program goes on with 
its nonnal execution- However, if the preferred version is not 
suppoited, then the DLL returns to the s^plication program 
a "not OK" flag and a list of versions t hat it does support 
firom its table of supported versions. In response, theappH:^ 
cation program look s up the versions on .this.list in a table 
o f compadble versions co ntained within the applicati^ 
progranLlf none are found, then the application pofonns an 
error trap. If one is found, then the application program calls 
the DLL to establish diat version as the one whidi will be 
used. The present invention advantageously utilizes a header 
file in order to designate DLL versions. 

16 Claims, 6 Drawing Sheets 



Q STAHT 



VERSION 
hJUMBER 



VERSKMNUUBER 
tN VERSION TABtE 



LOOKUP EACH 
SUPPOHTtDVERSDN 
W APPLICATION VERSION 
TABLE 




U.S. Patent May 27, 1997 sheet 1 of 6 



5,634,114 






WEST 



U.S. Patent May 27, 1997 sheet 2 of 6 5,634,114 



I 

^ APPLICATION I 



DLL. 



C START 

— ^— 1£! 

INmAL DLL CALL f 

I F 



9 



PREFERRED 
^VERSION 
^ NUMBER 

I 



15 



SET VERSION FLAG TO 
PREFERRED VERSION 




r 



I 



PREFERRED 
VERSION 
OK 



COm^lNUE 
EXECUTING 



Y 



16 



I 

I 

TIME 



10 



LOOKUP PREFERRED VERSION 
NUMBER IN VERSION TABLE 




SET VERSION FLAG TO 
PREFERRED VERSION 



T 



RETURN 



r 



13 



14 



FIO. 2 



U.S. Patent May 27, 1997 sheet 3 of 6 5,634,114 



. APPLICATION 

C START y -' 



J 



INITIAL DLL CALL 



DLL. 



PREFERRED 
VERSION 
NUMBER 



10 



LOOKUP 
PREFERRED 
VERSION NUMBER 
IN VERSION TABLE 



LOOKUP EACH 
SUPPORTED VERSION 
IN APPLICATION VERSION 
TABLE 





suppIrted 

VERSION ^ 
NUMBERS^ 
I ^18 



22 



MATCHING 
VERSION 
NUMBER 

i 
I 



I 



LOOKUP MATCHING 
VERSION NUMBER 
IN VERSION TABLE 



-10 




15 



SET VERSION FLAG 
TO MATCHING VERSION 



SET VERSION FLAG 
TO MATCHING VERSION 



J 



( CONTTINUE^ 
EXECUTING 



MATCHING 
VERSION 
OK^ 

TIME 



RETURN 



13 



14 



FIG. 3 



I 



U.S. Patent May 27, 1997 sheet 4 of 6 5,634,114 



^ START ^ 

UPGRADE DLL 
TO NEW CODE 



23 



J 



24 



ALTER VERSION # L-^^B 
IN HEADE R FILE | 

T 



compilblinkIoI^^^ 
create new dll 1 

GO"'' 



no. 4 



U.S. Patent May 27, 1997 sheet 5 of 6 5,634,114 




USE SAME HEADER FILE U^32 
THAT BUILT THE DLL 



I 



r 



GET VERSION NUMBER 
FROM HEADER FILE 



I 



COMPILE/LINK 
APPLICATION PROGRAM 



I 



,34 



,36 



LOAD APPLICATION PROGRAM 
INTO MEMORY AND EXECUTE 



I 



FIO. 5 



U.S. Patent 



May 27, 1997 



Sheet 6 of 6 



5,634,114 




5,6: 

1 

DYNAMIC LINK LIBRARY VERSION 
NEGOTIATION 

BACKGROUND OF THE INVENTION 

(1) Related Application 

This ai^lication is a continuatioD-iii-pait of Ser. No. 
154^69, filed Nov. 18, 1993, now abandoned whidi has 
been assigned to the assignee of this application. 

(2) Field of the Invention 

Hie present invention relates to the field of con^uter 
systems and con[q>uter software q)plications. Specifically, 
the present invention relates to the field of conoputer pro- 
gram development and execution. 

(3) Background 

Some programs executed by computer systems are con- 
stnicted using a partiailar set of development tools and are 
translated firom a high level programming language to an 
executable format according to a particular process. For 
instance, in order to develop a program written in a high 
level language, such as the C language, a program is first 
entered into an editor using the C instruction format and tiie 
"C program" is then coixqnled by a compiler program. Hie 
compiler program transfers the C instructions into assembly 
instructions r^resented as assembly code (often called 
machine code). The resultant output from the con^iler 
program is called the ".obj file" or object code. 

There may be several different object files stored on a disk 
drive or in a computer's memory and each may represent a 
different section of the high level program. Therefocre, a 
given C program may reference several object files. Such is 
well known in the prior art As the high level program is 
compiled, object files that are referenced by the program do 
not have to be con^iled again each time. This saves devel- 
opment time. 

Several object files may be combined together into a 
library file or "Jib file." Often used and rarely changed 
subroutines are compiled into object files and then placed 
into an object code library file so that they do not have to be 
coni^iled each and every time the C program is compiled. 
This is done in an effort to reduce the compile time of the 
Mg^ level program. If a subroutine is not going to change 
from one version of the hig^ level program to the next, there 
is essentially no need to Tecomphc the subroutine for each 
version of the high level program and therefore the object 
code library provides tiie compiled result when needed. In 
effect, the predefined object code files are "canned" subrou- 
tines that have been previously written and compiled and are 
not expected to change readily. 

A linker program is used to link the various object files 
together and to create a resultant executable file or ".exe 
file." Therefore, a higji level program is compiled then 
combined with previously compiled files that are referenced 
by the high level program (if any) and the total is linked to 
together to create an executable version of the program or 
"application." The executable file is the file that will be 
executed by the conqiuter system to peiform the instructions 
that were originally developed in the high level language 
(Le., of the C program). The executable file may be referred 
to as the "executable application." 

Also included in the above procedure is a file called tiie 
header file or "ii file." The header file contains, among other 
things, variable definitions and procedure and function defi- 
nitions HiSt may be incaiporated into the hi^ level program 
by reference, lliis purpose of the header file is to provide a 
readily available method of incorporating often used defi- 
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nitions into the hig^ level program without requiring the 
high level program (Le., the C i:rogram) to recite each 
definition individually. In other words, a group of variable 
definitions and or procedure or function definitions (tiiat are 
s expected to used by many applications) may be given a. 
common name, such as "<myfiles Ji>." Then, where ever the 
high level program includes a statement, such as the one 
listed below: 

# include <iTiyfi|gs.]i> 

10 

the compiler will read the header file for &e <myfilesJi> 
definitions and will incoiporate these definitions and/or 
instructions into the high ievd program at that point The 
result is that the definitions and/or instructions within &e 

15 <myfiles.h> group will be compiled by the compiler pro- 
gram as if they appeared in the high levd program originally 
at the location where the include statement appears. Use of 
a header file in the above configuration is also weU known 
in the prior art In the manner as described above a header 

20 file may be viewed as a development tool for the application. 
Developments have lead to the introduction of Dynamic 
Link library files (DLL files or DLLs) which are files that 
contain executable program code that corresponds to par- 
ticular subroutines and program sections. Similar to the 

25 notion of providing "canned" object files, Dynamic Link 
Library files provide "canned" subroutines in executable 
code fixwat that can be called by other ^plications to 
perform certain, known functions. 

At mn time, these subroutines can be directly called by 

30 the executable application in <ffder to perform various tasks. 
Therefore, the DLL must be resident in memory when &e 
application is executed. In other words, at execution time, 
the resultant executable code that is produced by the linker 
program from the hig^ level instructions will call certain 

35 subroutines for execution that exist within die DLL file. Hiis 
requires that the DLL be loaded into the coiiq)uter system's 
memory (or available for loading) before the executable 
program is executed. Therefore, before an executable pro- 
gram (created by the high level language) is executed, the 

40 DLL is loaded into the con^uter's memory. 

However, as is often the case, the DLL file that is loaded 
into memory may or may not be completely compatible with 
the current executable application that calls subroutines 
located within the DLL file. This problem arises because the 

45 DLL file called by the executable file can be updated and 
altered after the executable program is developed. 
Therefore, the DLL resident in memory may not be the DLL 
expected by the application file even Uiough the subroutine 
names (of die DLL) are the same. Fur&er, die executable 

so program can be altered and developed after the creation of 
the DLL file that is called by the executable program. 

It is important that the DLL file accept and supply the 
exact data and control interface expected by the executable 
file or serious errors will develop in the execution of the 

55 executable file. Therefore, it would be advantageous to 
provide a mechanism to insu re that the data interfaces 
between a DLL file and a n executable program are com pat- 
ible. It is turtner advantageous to provide a system and 
inethbd for insuring that the DLL resident in memory is that 

60 DLL anticq)ated by the executable applicatioiL The present 
invention provides such capability. 

It is further advantageous to be able to insure that a given 
subroutine within a DLL file and called by an executable file 
is the same subroutine that is expected by the executable file. 

65 Ihe present invention provides such advantageous function- 
ality. It is further advantageous to be able to negotiate which 
version or revision level of a given subroutine within a DLL 
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file win be used when called by an executable file in the case Further, the present invention supports negotiation of 

where there is not an exact match between the preferred whidi version or revision level of a given subroutine within 

version or revision levels but where diere is couG^^atibility a DLL file wiU be used when called by an executable file in 

between the executable and the DLL file in die sense that the case where there is not an exact match between the 

there is at least one version or revision level in common that s prefeaxed version or revision levels but \^ere there is 

each can operate with correctly. The preset invention compatibility between the executable and the DLL file in the 

provides such advantageous functionality. sense that there is at least one version or revision level in 



SUMMARY OF THE INVENTION 



common with which eadi can operate correctly. 
10 BRIEF DESCRIPTION OF THE DRAWINGS 



DETAILED DESCRIFnON OF THE 



A mechanism and method of providing version negotia- 
tion between a Dynamic T .inV Library file (DLL file) and an FIG. 1 illustrates the process used to create die application 
executable application is described. The present invention executable file and the DLL executable file from the appli- 
provides a version identification whidi is attributed both to cation source code file, the header file and the DLL source 
a particular DLL file and to a particular executable progranL code file. 

During execution of the plication program, it calls sub- piG. 2 illustrates the time sequence of the steps used by 

routines of the DLL. Im dally, th ec xecutaM e jpiogram call s the present invention in ensuring that the DLL version 

the DLL to,sjacdfy.the.VCTsioajiu robCT or ffieT>LL pref cued preferred by ttit application program is supported by the 

by ^c^plication^ nmgram. If the DLL can supportTlffis dt.l program. 

pr^fS^ version, then execution continues If not, then a 3 jUustiates the time sequence of the steps used by 

negotiation process oocuKm which the DLL provid^fif^ the present mvention in negotiating to seeif there is a match 

apphgbonwifc^^ nmnbers that the DLL between any of the DLL versions supported by the DLL and 

can support. The a^ca&ap lool^ at eadijersion on the ^hc DLL versions compatible witfi the application 

I supported list unuHflnar >ne with whi^ln^xecutc. If p^^g^ ^ ^^^^ ^^-^^ ^^^^ by the 

none of the vo-sxons match, then the apphcation program appUcation program is not supported by the DLL program, 
executes an error tcap operation and halts normal execution 

immediately ^ is a flow chart illustrating the steps used by the 

^ . . ^ , . present invention to construct a new DLL. 

The present invention advantageously utilizes version _ . _ ^ •„ ^ ^ j t_ 

tables both within the appUcation program and within the ™: ? ^ lUustrating the steps used by the 

DLLtoverifycompatihiUtyoftheprefenedversionaswell 3^ Present mvention to create an application program. 

as to negotiate compatibly if the preferred version is not ^^G. 6 is a logical block diagram of a general purpose 

supported. The application program makes an inirial call to computer system suitable fw executing the present inven- 

the DLL to specify the DLL version with viliich it prefers to ^^o**- 

cpaate. The DLL compares this preferred version number to 

the version numbers that it supports, which are in a table 3. '^'^'''^^^^ i^^^^A^ 

within the DLL. This table is caUed the supported DLL INVENTION 

version table. In the case where the preferred version Hie present invention includes an ^Jparatns and method 

matcfaesoneof the entries in this table, then die DLL returns for providing a version negotiation c£^abili^ between a 

an **preferred version OK" flag to the application program. Dynamic Link Library ('DLL") and an associated applica- 
In this case, die application program goes on with its normal ^ tion program. Within tiie discussions hwein, the "application 

execution. However, if the preferred version is not supported program" refers to the executable code program that is 

(ie. its venion number is not found in the si^ported version compiled and linked and is used to execute an application, 

table), then the DLL returns to the application program a In the course of its execution, flie ^jplication program calls 

'*preferred version not supported" flag and a list of versions subroutines within the DLL The present invention can 
that it does support TTiis list of versions returned comes ^5 operate effectively on a desktop or general purpose com- 

firom the table of siq)ported versions within the DLL. In puter system. An exemplary conqKiter system is described 

response, the application program compares diis list with the herein. 

versions with which it is compatible— that is, it looks up in the following detailed description of the present inven- 

each version on this list in a table of version numbers tion numerous specific detafls are set fortfi in order to 

contained witiiin the appHcation program. This table is provide a thorough understanding of die present invention. 

caUed the compatible version table. However, it wiU be obvious to one skiUed in the art fliat the 

The present invention preferably advantageously utilizes present invention may be practiced without these specific 

the header file in order to designate a DLL version identi- details. Id other instances well known methods, procedures, 

fication and a version identification within the application components, and circuits have not been described in detail 
program. In addition to the designation of the cuaent 55 so as not to unnecessarily obscure the present invention, 

version, die heado- file may contain some or all of tiie entries Some portions of the detailed descriptions which follow 
tfor the supported version table widiin the DLL and fffljhe_ are presented in terms of algoritfuns and symboJic repre- 

^ compatible version table \wdiinjheapidication.y^^ sentations of operations on data bits widiin a computer 

^ fications made to the DLL file after the develqpinent of die memory. These algoritfimic dcscrq)tions and representations 
plication program will be detected by the present go are die means used by diose skilled in die data processing 

invention, tiius preventing run-time OTors widiin the a^jpli- arts to most effectively convey die substance of dieir work 

cation program caused by such unexpected modifications. to odiffs skilled in die art An algoritimi is here, and 

Thus, the present invention insures that there will always generally, conceived to be a self-consistent sequence of steps 

be an expect data interface between the DLL and the leading to a desired result The steps are those requiring 
exeoitable program which relies on the DLL. Further, the 65 physical manipulations of physical quantities. Usually, 

present invention prevents a later modified application pro- though not necessarily, these quantities take the form of 

gram firom calling an earlier version of the DLL. electrical or magnetic signals c^>able of being stored. 
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transfeiredi combined, compared, and otherwise manipu- 3. Header file 2 is prefaably used to aeate the executable 

lated. It has proven convenient at times, princ^ally for files for both the plication and the DLL. For example, 

reasons of conmion usage, to refw to these signals as bits, within the header file called my_file, there is a statement 

values, elements, symbols, characters, tenns, numbers, or that will define my_JDLL_version as a particular version 
the like. 5 numbff. My_file can later be used in die generation of, and 

It ^ould be bOTie in m\nd^ however, that aQ of these and my_JDLL_version can be incorporated into, both the appli- 

CTtnilflr terms are to be associated with the appropriate cation executable file and die DLL executable file, 

fdiysical quantities and are merely convenient labels applied Once translated, the plication executable file 5 and the 

to these quantities. Unless specifically stated otherwise as DLL executable file 6 contain the DUL version number 

apparent from the following discussions, it is appreciated preferably as specified in header file 2. The header file 

that throughout the present invention, discussions utilizing supplies much more than sinq)Iy a vision number in general 

terms such as **processing" or "con:^)uting" or "calculating" practice. However, tiie present invention is directed at ver- 

or "determining" or "displaying" or the like, refer to the sion negotiating capability. Other information supplied by 

action and processes of a conq>uter system, or similar the header file is not pertinent to the present invention and 

electronic computing device, that inanipulates and trans- is not discussed in detail herein. 

forms data represented as physical (electronic) quantities FIG. 2 is a nmlti-process flowchart illustrating the inter- 
within the computer system's registers and memories into action between the qiplication program as one process and 
other data similarly represented as physical quantities within the DLL program as a second process. FIG. 2 shows the 
the con^uter system memories cs registers or other such steps each process takes in the case where the preferred 
information storage, transmission or display devices. version number specified by the application is supported by 

DLLs are advantageous in part because they provide, as the DLL. 

discussed, routines that are compiled and are in exeaitable Sometime after the application starts its execution (step 

form. Before an application program may utilize a DLL, it 7), an initial call to the DLL is made (step 8). In initial DLL 

must be loaded into the computer system* s memory or be call 8 the a|:plication program passes the viue of prefened 
similarly accessible on disk drive. During run time, an ^ version number 9 to tiie DLL. Prefeired version number 9 is 

executable program may call subroutines of the DLL to derived from head^ file 2 during the translation of ^li- 

perform a variety of tasks. Input/ou^ut interface, disk cation executable file 5. ftefened version number 9 specifies 

j control, or grai^iics display, anaong some of the many tasks the version of the DIL program that tiie application prefers 

/ available. One of the many benefits of using a DLL file is to work with, as was specified in header file 2 at &e time 
j that often several applications, tiiat may be resident in a ^ con^ilei/assembler 4 translated the application program, 

j computer memory at the same, may use the same procedures In response to tiiis initial DLL call, the DLL looks up 

for perfQrming routine tasks, such as display interface. preferred version number 9 in its version table (step 10). 

Instead of each appUcation program having its own copy of step 11 decides whetho- or not preferred version 9 is 

the procedure, only one copy need to be resident in the supported, based on whether or not it is found in tiie DLL's 

computer RAM at a time and can be shared by the appli- table of versions that it supports. 

cations Therefore, eadi prop^ inay use the DLL subrou- 2 shows the process flow for the case where this 

tme and the amount of RAM reqmred to contain all of die ^^^^^ ^ supported, while FIG, 3 shows tht case 

programs at any given tune may be sigmficantiy reduced. ^^ere the prefened version is not supported. If tiie prefened 

Also, DLLs are helpful because there may be minor ^ version 9 is supported, control passes on to step 12. In step 

modifications to the subroutines witiiin the DLL file to 12, which is optional, the DLL sets the current value of an 

upgrade Ihem to new system environments without having internal version flag to preferred version number 9. This flag 

torecompileandlinkeachoftheapplicationsdiatrelyondie can be used during the execution of tiie DLL to ensure 

DLL flle. This is true provided tiie upgrades are relatively compatibility witii the data passed b^een the application 

minor and do not interfere witii tiie data interface expected and die DLL. For exan^le, in the case where a version otiier 

by the ^plication progranL For instance, if the display than die most recent version is agreed upon in the negotia- 

screen was upgraded or certain aspects of tiie computer woe tion process of tiie current invention, the flag can be used 

upgraded, the DLL subroutines caild be slightiy altered to widun a more recently updated subroutine to switch control 

adapt to die new environment Since the plication pro- to different, perhaps older code so as to preserve support for 
grams call the DLL subroutines to perform tiie routine tasks ^ the older DLL/application interface, 

of saeen display, tiiese applications would automatically be Next in step 13, tiie DLL returns '^ireferred version OK" 

updated by die DLL update even tiiough tiie ^Ucations flag 14 to tiie appHcation. In response to receiving "preferred 

tiiemselves were never modified. As such, tiiere is no need version OK" flag 14, tiie appUcation program in optional 

to reconqjile and relink tiiese ^Ucation programs. step 15 sets tiie airrent value of its version flag to prrfencd 

However, if the upgrades to the DLL become severe and 55 version number 9. This flag can be used during the appli- 

interfere with the data interchange expected by the appUca- cation programs execution to ensure DLL version gnmpflf- 

tion program, then the iq>dated version of the DLL may ibility. For exaiiq)le, in die case where a version other than 

cause the application program to faiL The pref acred embodi- the preferred version is agreed upon in the negotiation 

ment of the present invention pxvents such failures by process of the current invention, the flag can be used to 
providing a version negotiating cj^jability between the ^pli- ^ switch program control to a different, perhaps older DLL call 

cation program and the DLL file. so as to preserve compatibility with the older DLL/ 

Referring to FIG. 1, the overall operation of the present application interface, 

invention operates by placing an instruction within header Next, die plication continues executing, knowing that 

file 2 that defines a particular version numbex. Preferably, DLL version compatibility has been assured by die sequence 
diae is a sin^ header file 2 that is invoked by and used in 6S of st^ described in reference to HG. 2. 

the translation (Le, the conqnlation or assembly) of botii tiie FIG. 3 is a multi-process flowchart illustrating tiie intcr- 

ai^lication source code file 1 and the DLL source code file action between the ^^lication program as one process and 
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the DLL program as a second process. FIG. 3 shows the In the case wheie a newer (upgraded) version of the DLL 

ste^s each process takes in the case where the prefeoed is translated into DLL executable file 6 subsequent to the 

version number specified by the ^>plication is not supported translation of the application program into application 

by the DLL and version negotiation is required. executable file 5, then the version definition section of the 

Steps 7, 8, 10 and U as shown in FIG. 3 are identical to 5 header file 10 is updated according to the present invention, 

those shown in FIG. 2. That is, soon after the appUcation "^""^ ^he new DU. is coi^Ued ^d linked, the upgraded 

starts in step 7, it makes an initial caU to the DLL^ step 8. "^^t^ ^^"^ m ^^'^P^^ 

T 11 *u r J • the new version of DLL executable file 6. Assummg the 

In this call, the application program passes prefeired version ^ *i_f* 

numlxx9tothe DLLas the v^on of the DLL program that '^'^Z ^ V or at least not 

it would prefer to work with. Next, the DLL loob up the lo "^^^Mated, tten it wfll contam the old or previou^ v<^on 

™.-f^^ ,„ toKi- 1 ftf number, as defined m the previous version of header file 2 

prerecred version number m its version table (step 10). ^, ^ j * ^ i ^ 

V r / jjjaf ujgd translate it 

However, in step 11, toe Mi discovers diat thef^rfared ^ in this case DLL executable file 6 contains a 

version is not s^pIWIteA Accordmg^^^^ i«ssed from ^ ^ ^ „^ in the header file, but 

deasion step U to rtqp 17 to step 17, the DLLretumsto fte ^^^^j^ 5 ^ ^ 

^phc^ona-nrtOK" or •^feircd version notsuppo^^ « af&ication program, it makes initial DLL call 8 spediying 

flag indicating that preferred version number 9 is not sup- ^5 ij t^t t ^ . , * j • ^ 

Ajjj*I 11, •* 4, i -x r . the older DLL version number as prefaied version number 

ported. Additionally, it returns a list of supported version « t* • -t-i ^ • <.i_ * i j * j 

^jjjj^g 9. It IS possible, but not certam, that the newly updated 

version of DLL executable file 6 will find this older version 

In response to the notOIC flag returned by the DLL, the number m its table of versions that it can support and thus 

apphcation program continues on to the version negotiation ^ ^Wefored version QIC' flag 14 to tiie application 

portion of the present inventioa The application program program. 

looks up each member of the list of supported version wi,»*k«. ^ tr. ^^^...^^ 

, '^-o . . ^ . , Whether or not to place the previous version number m 

numbers 18 in its version table (step 19). *i. * 1.1 * • • j .j ^ ^ 

□ ^ Y«ai 11 uiv. yoi^y Compatible versions is deaded by the program- 

Ifno supported versionmatches a vffsion with whichitis ^5 ma updating the DLL, This decision is made based on 

compatible (as stored in the appUcation program's version whether the changes in the new update of flie DLL are minor 

table), then decision stq) 20 passes control on to step 21. and invisible to the appHcation program or whether diey are 

Step 21 is an error trap, which typically tcnninates the significant and involve the manner in which mforma- 

execution of the appUcation program after giving a suitable control is passed back and forth between the DLL 

error message. A number of tasks may occur in step 21, 3^ and the appUcation program. If the former, then the pro- 

induding terminating the appUcation program, commum- grammer can safely place the old version number in the 

eating with an iiqmt/output device (such as a display unit) to djx's table of supported versions. If the latter, then the 

inform the user of the error, etc programmer can not, unless he makes use of the version flag 

Alternatively, if there is a supported vision that matches that is set in step 12 and includes in the new version of ttie 
an entry in its table of compatible versions, then decision 35 DLL optionaUy executed code that interfaces with the appU- 
step 20 passes control on to stq) 8. This execution of step 8 cation program via the old version's interface. This corn- 
makes an initial caU to the DLL specifying matching version patibiUty code would be conditionaUy executed only if the 
number 22 as the varsion that it would Uke the DLL to current value of fliat version flag indicates that the interface 
support of an older version of the DLL has been agreed iq)on during 

In response to receiving this initial call specifying match- 40 the version negotiation process of the present invention, 

ing version 22 as the DLL version that the appUcation piG. 4 is a flow chart for generating a new version of the 

program prefers, Ae DLL looks up matching version 22 in DLL. These steps are utilized by the present invention when 

its version table (step 10). Next decision step 11 determines the DLL is uiitially created or when the DU. is updated firom 

that matching version number 22 is supported— this favor- one version to another to an extent that may interfere with 

able result is guaranteed because matching version number 45 the previous and expected data interchanges and interfeces 

22 was originaUy suggested by the DLL in return stq) 17. between die appUcation and the DLL files. The flow begins 

Accordingly, control passes to step 12, in which the DLL at step 23 and continues to step 24 wherein the DLL source 

sets its intonal version flag to matching version number 22. files are updated with new or modified program.code, thus 

Next m stq) 13, the DLL returns to the appUcation '*match- altering the routines wifliin the DLL 14. Step 24 also 

ing version OK" flag 14. 50 includes die case where the DLL is initiaUy generated fi:om 

In response to ''matching version OIC* flag 14, the appU- scratdL Step 24 may indude the addition of new commands 

cation program in optional step 15 sets its internal version to the existing routines, the addition of new routines entirely, 

flag to matching version number 22. The appUcation pro- the removal of routines from the program code, or other 

gram then continues to execute knowing that it has success- altaations. 

fiiUy negotiated version compatibiUty with the DLL. 55 After DLL source code file 3 has been updated, header file 

In the case where both appUcation executable file 5 and 2 is altered such that it contains a new version number to 

DLL executable file 6 are created using the same version of correspond to die updated DLL (step 26). Portions of heads' 

header file 2, then preferred version numba 9 is guaranteed file 2 are indudcd into die DLL when the DLL program is 

to be fcmnd in step 10 in the DLL's table of siq)ported translated. Bdow is an illustrative statement that the present 

version numbas. This is the expected usual situation. If both 60 invention indudes in the header file 10 to define the version 

the DLL 14 and the appUcation program 12 contain the same number: 

version number, then decision step U wiU find tiiat flie «^ 

pr^erred version is supported and step 13 wiU return ^ 

'^preferred version OK" flag to the appUcation program. In * myju^vosiaa 3.21. 

this case, there should be con^iatible data interchange 65 The version, 3.21, will be updated in step 26 depending on 

between the subroutine calls of die appUcation program and its previous value and to reflect the changes made to the DLL 

the corresponding subroutines contained within DLL 14. in st^ 24. 
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Id step 28, the DLL is translated to generate an executable 
DLL file 6 tiiat will contain the version, 3^1, that was set in 
step 26. DLL source code file 3 includes a statement that 
incorporates the above definition into die DLL 14 during 
translation. Such a statement is shown below: s 

Include ^iiyfi]e> 

By using the above statment, DLL will import from header 
file 2 die current version value, 3.21. This version number 
will be associated with the variable or label called lo 
my_J)LL_version. 

FIG. 5 illustrates the major steps of the present invention 
that relate to the generation and execution of an i^Hcation 
program tiiat utilizes routines of the DLL. The flow begins 
at step 31 and flows to stq> 32. The application program, is 
written in a hig^ level or assembly language, uses same 
header file 2 diat was used to generate the DLL. In step 34, 
the application program will utilize a statement to include 
the definition section of the header file 2 that includes the 
current DLL version. Hiis statement is similar to the state- 20 
ment as used by the DLL. Therefore, the application pro- 
gram will directly have access to the version number of the 
latest DLL that was iq)dated because both the DLL and the 
application program utilize the same header file 2. 

In step 36 of HG. 5, the present invention compiles or 2S 
assembles and links the application program. In step 38, die 
present invention loads die DLL executable file 6 into die 
memory (sudi as RAM 102) of die computer system 112 
(see FIG. 6) and also loads the application executable file 5 
into the con^uter system memory 102. In step 38, the 30 
conq>uter system 112 then executes the application program 
12 which includes the DLL version negotiation process 
discussed above. 

FIG. 6 shows a general conq)uter system 112 within 
which die embodiments of the present invention can operate. 35 
The computer system 112 is enable of executing die 
q)plicatLon program and the DLL ps-ogram. Further, the 
general purpose computo* system 112 is capable of operat- 
ing the compiler program and the linking program as dis- 
cussed above. 40 

In general, conq)uter systems 112 used by die preferred 
embodiment of the present invention comprise a bus 100 for 
communicating information, a central processor 101 
coupled with the bus for processing information and 
instructions, a random access memory 102 coupled with the 45 
bus 100 for storing information and instructions for the 
central processor 101. a read only memory 103 coupled with 
the bus 100 for storing static information and instructions for 
the processor 101, a data storage device 104 such as a 
magnetic disk and disk drive coupled with the bus 100 for so 
storing information and instructions, a display device 105 
coupled to the bus 100 for displaying information to the 
con^juter user, an alphanumeric input device 106 including 
alphanumeric and function keys coupled to die bus 100 for 
communicating infcHmation and command selections to the 5S 
central processor 101, a cursor control device 107 coi^led 
to the bus f<s communicating user input information and 
command selections to the central processor 101, and a 
signal generating device 108 coupled to die bus 100 for 
communicating command selections to the processor 101. 60 

The display device 105 of FIG. 6 utilized widi die 
computer system 112 of the present invention may be a 
liquid crystal device, cathode ray tube, or other display 
device suitable for creating gr^hic images and alphanu- 
meric (diaracters recognizable to the user. The cursor control £5 
device 107 allows the computer user to dynamically signal 
the two dimensional movement of a visible symbol (pointer) 



on a display screen of the display device 105. Many in^le- 
mentations of the cursor control device are known in the ait 
including a trackball, mouse, joystick or spedal keys on the 
alphanumeric inpat device 105 capable of signaling move- 
ment of a given direction or manner of displacement It is to 
be appreciated diat the cursor means 107 also may be 
directed and/or activated via input firom the keyboard using 
special keys and key sequence commands. Altemativdy, die 
cursor may be directed and/ca- activated via input from a 
number of specially adapted cursor directing devices. 

The preferred embodiment of the present invention, a 
method and mechanism of providing version negotiation 
between a Dynamic Link Library and an executable file, is 
described. While die present invention has been described in 
particular embodiments, it should be qipreciated diat the 
present invention should not be constmed as limited by such 
embodiments, but rather construed according to the below 
claims. 

I daim: 

1. A method of executing an application program and a 
Dynamic Link library (DLL), con^irising: 

said application program making an initial call to said 
DLL to specify a preferred version number, 

said DLL looking up said preferred version number in a 
supported version table, and, if found, returning to said 
application program a "preferred version OK" 
indication, and, if not found, returning to said applica- 
tion program botii a '^preferred version not supported** 
indication and at least one supported version number 
from said supported version table, said supported ver- 
sion table including a set of indq)endent version numr 
b^ that said DLL supports; 

said application program continuing its execution in 
response to said "prefcned version OK** indication; and 

said q)plication program, in response to said ''preferred 
version not supported** indication, comparing each said 
supported version number against each of a set of 
independent version numbers widi which said DLL is 
coixq>atible, said conqiatible version set being held in a 
compatible version table, and, if diere is no match there 
between, performing an error trap operation, and, if 
there is a match there between, making an initial call to 
said DLL ^ecifying as said preferred version number 
the version nmnber of said match. 

2. A method according to claim 1, further comprising: 
said DLL setting the value of a current version indicator 

internal to said DLL to said preferred version just prior 
to returning said ''preferred version OK" indication, 
said DLL using said internal version indicator to ensure 
support of said preferred version. 

3. A mi^od according to claim 1. further con^ffising: 
said application program setting the value of a current 

version indicator internal to said application program to 
said preferred version just prior to continuing its execu- 
tion. 

4. A metiiod of negotiating dynamic link library (DLL) 
version compatibility, comprising: 

(a) translating a header file and a DLL source code file 
into a DLL, said header file specifying a current DLL 
version number, and said DLL having a table that 
includes a s^ of independent version numbers which 
said DLL supports: 

(b) translating said header file and an application source 
file into an ^Hcation program, said header file speci- 
fying an expected DLL version number, and said appli- 
cation program having a table that incudes a set of 
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independent version numbers witii which said applica- 
tion program is compatible; and 
(c) exeoiting said application program and said DLL, said 
execution comprising: 

(i) . said application program making an initial call to 
said DLL to specify as a prefoied version number 
said current DLL* version number from said header 
file; 

(ii) said DLL looking up said preferred version number 
in said supported version table, and, if found, return- 
ing to said application program a *^prefeired version 
OK" indication and, if not found, r^uming to said 
application program bolh a **prefexred version not 
supported" indication and at least one supported 
version number from said supported version table; 

(iii) said application program continuing its execution 
in response to said '*preferred version OK" indica- 
tion; and 

(iv) said ^plication program, in response to said **pre- 
fecred version not supported" indication, con[q)aring 
each said supported version number against each 
compatible version number in said con^atible ver- 
sion table, and, if there is no matdi there between, 
performing an etror trap operation, and, if there is a 
match there b^een, making an initial call to said 
DLL speciiying as said preferred version number the 
version number of said match. 

5. A method according to claim 4, wherein said execution 
step further comprises: 

(v) said DLL siting the value of a current version 
indicator internal to said DLL to said preferred version 
just prior to returning said ••prefecred version OK" 
indication, said DLL using said internal version indi- 
cator to ensure support of said preferred version. 

6. A method according to claim 4, wherein said execution 
step furtho- con^ses: 

(v) said application program setting the value of a onrent 
version indicator internal to said application program to 
said preferred version just prior to continuing its execu- 
tion. 

7. Id a computer system comprising a bus, a processor 
coupled to said bus, a memory coupled to said bus and an 
input/output device coupled to said bus, a method of execut- 
ing an application program and a Dynamic l ink- Library 
(DLL), said m^od cooqmsing the conq)uter ii!q>lemented 
steps of: 

making an initial call originating from said application 
program to said DLL to specify a preferred version 
number associated with said af^licarion program; 

looking up said preferred version number by said DLL in 
a supported version table stored within said DLL, said 
supported version table including a set of indq)endeDt 
version numbers that said DLL supports; 

returning to said plication program a **prefeired version 
OK" indication if said preferred version number is 
located within said supported version table; 

returning to said application program both a "^prefenred 
version not supported" indication and at least one 
supported version number from said supported venion 
table if said preferred version is not located wi&in said 
supported version table; 

contLmiing exeoition of said application program in 
response to said "preferred version OK" indication 
returned thereto; and 

said appKcation program, in response to said "prefened 
version not siq>ported" indication, comparing each said 
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supported version numba against each of a set of 
independent version numbers with which it is 
compatible, said con^tible version set being held in a 
compatible version table stored within said application 

5 program, and, if there is no match there between, 
pecfcnning an error trap operation, and, if there is a 
match there between, making an initial call to said DLL 
specifying as saidprefened version number the version 
number of said match. 

10 8. A method according to claim 7, further comprising the 
step of: 

said DLL setting the value of a current version indicator 
internal to said DLL to said preferred version just prior 
to returning said "preferred version OK" indication, 
IS said DLL using said internal version indicator to ensure 
support of said prefen^ed version. 

9. A method according to daim 7, further comprising the 
step of: 

said application program setting the value of a current 
^ version indicator internal to said application program to 
said preferred version just prior to continuing its execu- 
tion. 

10. In a co^^)uter system comprising a bus, a processor 
coupled to said bus, a memory coupled to said bus and an 

^ input/output device coupled to said bus, a method of nego- 
tiating dynamic Unk Ubrary (DLL) version compatibility, 
said method comprising the steps of: 

(a) translating a header file and a DLL source code file 
into a DLL, said header file specifying a current DLL 
version number, and said DLL having a table that 
includes a set of independent version numbers which 
said DLL supports; 

(b) translating said header file and an application source 
33 file into an application program, said header file speci- 
fying an expected DLL version number, and said appli- 
cation program having a table that inciudes a set of 
independent version numbers with which said DLL is 
conq>atible; and 

40 (c) executing said application program and said DLL, said 
execution comprising: 

(i) fnaiHng an initial raH ori^nating firom said appli- 
cation program to said DLL to specify as a preferred 
version number said current DLL version number 

45 from said header file; 

(ii) looking up said preferred version number by said 
DLL in said supported version table stored with said 
DLL, and, if found, returning to said ^plication 
program a '*preferred version OK" indication and, if 

so not found, returning to said application program both 

a *^ferred version not supported" indication and at 
least one suppcHted version number from said sup- 
ported version table; 
(iiO continuing execution of said ^plication program 
55 in response to said "preferred version OK" indication 

returned thereto; and 
(iv) said ^plication program, in response to said "pre- 
ferred version not supported" indication, coII^)aring 
said supported version number against each said 
60 con^atible version number, and, if there is a match 

tiiere between, making an initial call to said DLL 
specifying as a preferred version number the version 
number of said match. 
IL A method according to daim 10, wherein step (iv) 
65 performs the furtiio* step of: 

if there is no match between said returned version sisp- 
ported against said compatible version table stored 
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within said appHcation program, perfonning an error 
trap operation. 

12. A method according to claim U, wherein said execu- 
tion step further conqaises the 5tq> of: 

(v) said DUL setting the value of a cmrent version 5 
indicator internal to said DLL to said preferred version 
just prior to returning Mid '^preferred version OK" 
indication, said DLL using said intenial version indi- 
cator to ensure support of said prefencd version. 

13. A method according to daim 11, wherein said execu- 
tion step further comprises the st^ of: 

(v) said application program setting the value of a cuxrent 
version indicator internal to said application program to 
said preferred version just prior to continuing its execu- 
tion. 

14. A coii^)uter system comprising: 

a bus, a processor coupled to said bus, a memory coi^led 
to said bus and an input/output device coupled to said 
bus« wherein said processor iiiq)lements a method of ^ 
executing an application program and a Dynamic link 
Library (DLL); 

said processor making an initial caU originating from said 
application program to said DLL to specify a preferred 
version number associated with said application pro- 25 
gram; 

said processor looking up said preferred version number 
by said DLL in a si^ported version table that includes 
a set of version numbers which said DLL supports; 

said processor returning to said qyplication program a 
"preferred version OK*' indication if said preferred 
version number is located within said supported version 
table; 
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said processor returning to said ^Ecation program both 
a **prefeired version not supported" indication and at 
least one supported version number from said siq>- 
ported version table if said preferred version is not 
located within said supported version table; 

said processor continuing execution of said application 
program in response to said **prcfcEred version OK" 
indication returned ther^; and 

said application pax>gram, in response to said '*prefecred 
version not supported" indication, instructing said pro- 
cessor to compare each said supported version number 
against each of a set of ind^ndent version numbers; 
with which said DLL is conq>atible, said set being held 
in a conq)atLble version table stored within said appli- 
cation program, and, if there is no match diere between, 
performing an errcH* trap operation, and, if there is a 
match there between, said processor making an initial 
call to said DLL specifying as said preferred version 
number the version nurnber of said match. 

15. A computer system according to daim 14, herein 
said DLL instructs said processor to set the value of a current 
version indicator internal to said DLL to said prefecred 
version just prior to returning said '^preferred version OK** 
indication, said DLL using said internal version indicator to 
ensure support of said preferred vo^ion. 

16. A computer system according to daim 14, wherein 
said application program instructs said processor to set the 
value of a current version indicator internal to said plica- 
tion program to said preferred version just prior to continu- 
ing its execution. 



